Ip core design supporting user-added scan register option

ABSTRACT

An integrated circuit carries an intellectual property core. The intellectual property core includes a test access port  39  with test data input leads  15,  test data output leads  13,  control leads  17  and an external register present, ERP lead  37.  A scan register  25  encompasses the intellectual property core and ERP lead  37  carries a signal indicating the presence of the scan register.

This application is a divisional of application Ser. No. 12/203,475,filed Sep. 3, 2008;

-   which was a divisional of application Ser. No. 11/380,965, filed May    1, 2006, now U.S. Pat. No. 7,441,170, issued Oct. 21, 2008;-   which was a divisional of application Ser. No. 10/705,648, filed    Nov. 10, 2003, now U.S. Pat. No. 7,065,692, issued Jun. 20, 2006;-   which was a divisional of application Ser. No. 09/812,220, filed    Mar. 19, 2001, now U.S. Pat. No. 6,658,615, issued Dec. 2, 2003;-   which was a divisional of application Ser. No. 09/107,105, filed    Jun. 30, 1998, now U.S. Pat. No. 6,223,315, issued Apr. 24, 2001;-   which claims priority from Provisional Application 60/051,377, filed    Jun. 30, 1997

FIELD OF THE DISCLOSURE

The disclosure relates generally to testing of integrated circuitshaving embedded cores and, more particularly, to a core design thatefficiently supports a user-added scan register option.

BACKGROUND OF THE DISCLOSURE

Rapid design and deployment of high complexity integrated circuits (IC)can be achieved by reuse of preexisting intellectual property (IP)cores, such as digital signal processors, microcontrollers, processors,I/O peripherals, and memory. Such IP cores are discussed in “Blocking ina System on a Chip”, by Hunt and Rowson, published in the November 1996edition of IEEE Spectrum and incorporated herein by reference. Marketingof IP cores, as a way to expedite the fabrication of highly complexsystem chips, changes the way the cores are designed for testability.Typically, most IP cores were first designed as stand alone ICs to beused on a circuit board. With today's advanced IC fabricationtechnology, it is possible to migrate what was once a circuit board ofplural ICs into a single IC comprising plural cores embedded therein.Thus a transition from IC to embedded IP core is a technology trend.

Many of the same testing problems currently seen in circuit boardsdesigned with multiple ICs will be seen in ICs designed with multiplecores.

The use of IC resident testability standard, IEEE Std 1149.1,incorporated herein by reference, has proven to be effective inresolving most test problems related to testing ICs and theinterconnections between ICs at the circuit board level. This standardshould be effective in resolving problems related to testing cores andthe interconnections between cores at the IC level as well.

FIG. 1 illustrates the architecture of IEEE Std. 1149.1 implemented in aconventional IC. The architecture includes (1) a test access port (TAP)11 which further comprises a TAP controller and an instruction register,(2) a plurality of test data registers (boundary scan register andothers), and (3) an 1149.1 test port interface which provides externalI/O to the architecture via the TAP controller. These elements and theiroperation and function are well known and described in IEEE Std. 1149.1.The boundary scan register includes a scan cell at each input, output,control, and input/output pin of the IC.

In normal mode, the IC operates normally to internally process andexternally communicate signals to other ICs via the transparent boundaryscan register. In a first test mode, the functional circuitry of the ICis disabled and the boundary scan register is accessed and controlled,via TAP signal lines at 13, 15 and 17, to communicate external testsignals between ICs to verify their interconnectivity. This externalinterconnect test mode is invoked by scanning an 1149.1 Extestinstruction into the instruction register of the TAP 11. In another testmode, the IC's functional circuitry may be functionally disabled butconfigured to be testable via scan access (from the TAP) to one or moreof the test data registers. Instructions scanned into the instructionregister of the TAP are used to connect the TAP up to a selected testdata register(s), i.e. the boundary scan register and/or internal testdata registers, so that serial test data can be input and output to theregister to effectuate a given test or other type of operation. Forexample; when the Extest instruction is loaded into the instructionregister, the TAP selects and connects up to the boundary scan registervia its serial input 15, serial output 13, and control signals 17. Onceconnected, the TAP responds to the external test port signal pins of theIC to output control to the boundary scan register to communicate testdata to the boundary scan register to execute interconnect testing.Similarly, other instructions can be loaded that allow the TAP to selectand connect up to other test data registers so that other types ofoperations such as; internal scan testing, built in self test triggering(1149.1 Runbist instruction), or IC serial bypassing (1149.1 Bypassinstruction), can be performed.

While the complete 1149.1 architecture of FIG. 1 is almost alwaysimplemented in ICs to provide the external and internal testingmentioned above, it may not be completely implemented in an IP coreversion of an IC. More specifically, the boundary scan register portionof the architecture may not be implemented in IP cores becausecompetition between IP core venders is largely based on IP coreperformance, and the boundary scan register inherently adds adisadvantageous delay (through a switch or multiplexer) to each input,output, and control (e.g. three-state control) signal associated withthe IP core's boundary. A boundary scan register that is provided aspart of an IP core will herein be termed a core-provided boundary scanregister. An IP core having its own core-provided boundary scan registerhas the same general structure as the IC of FIG. 1.

If an IP core provider does not implement the boundary scan register dueto performance considerations, and if the core itself cannot be modifiedby the user (i.e. a hard core), then the IP core user will have to add aTAP and boundary scan register around the IP core if the user wishes toachieve interconnect testing via boundary scan. Surrounding an IP corewith a TAP and boundary scan register for the purpose of isolating theIP core and performing interconnect testing between the IP core andother IP cores is a known prior art technique and is illustrated in FIG.2.

Within the broken-line box of FIG. 2 is an IP core with appropriate1149.1 architecture, but without the boundary scan register andassociated signal lines 13, 15 and 17 of FIG. 1. A user-added boundaryscan register 25 and TAP 23 are shown outside the broken-line box. Theboundary scan register 25 is unshaded to distinguish it from thecore-provided boundary scan register of FIG. 1. The TAP 23 is providedby the user to access and control the user-provided boundary scanregister 25 and is separate from the TAP 21 of the IP core. The TAP 21differs from TAP 11 and TAP 23 because TAP 21 does not supportconventional 1149.1 boundary scan instructions, namely Extest andSample/Preload. The approach shown in FIG. 2 disadvantageously requiresadding TAP 23 to provide access to and control of the user-addedboundary scan register. Also, the user must be able to select either theTAP 21 for internal testing/emulation of the IP core, or the TAP 23 forinterconnect testing (via the boundary scan register) between the IPcore and other IP cores or circuits residing in the IC.

It is therefore desirable to permit the user to add boundary scan to anIP core without the overhead associated with adding a separate TAP tocontrol boundary scan.

The disclosure permits reuse of the IP core's TAP to access a user-addedboundary scan register.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a conventional integrated circuit with 1149.1boundary scan capability, or alternatively, a conventional IP core withcore-provided 1149.1 boundary scan capability.

FIG. 2 illustrates the conventional configuration of an IP core withuser-added boundary scan.

FIG. 3 illustrates an IP core with user-added boundary scan according tothe present disclosure.

FIG. 3A illustrates an IP core arranged to support a user-added boundaryscan register according to the present disclosure.

FIG. 4 illustrates in greater detail the TAP control signals of FIGS. 3and 3A.

FIG. 5 illustrates the structure of the instruction register in the TAPof FIGS. 3, 3A and 4.

FIG. 6 is similar to FIG. 3 and illustrates another user-added scanregister according to the disclosure.

FIG. 6A is similar to FIG. 3A and illustrates an IP core arranged tosupport the user-added scan registers of FIG. 6.

DETAILED DESCRIPTION OF THE DISCLOSURE

Example FIG. 3 illustrates, within the broken-line box, an IP corewithout a boundary scan register but having the necessary access andcontrol lines for connection to a user-added scan register. In exampleFIG. 3, it is seen that the TAP 39 of the IP core provides signal lines13, 15 and 17 for accessing and controlling a user-added scan register25. In this example, the user-added scan register is a boundary scanregister (shown unshaded to distinguish from the core-provided boundaryscan register of FIG. 1). The TAP 39 also includes an external registerpresent (ERP) input 37 for indicating to the TAP whether or not auser-added scan register has been implemented.

Example FIG. 4 shows in more detail the IP core TAP 39 of FIG. 3, whichincludes the conventional 1149.1 test port signals of TAP 21 (see FIG.2), namely test data input (TDI), test clock (TCK), test mode select(TMS), test reset (TRST), and test data output (TDO), along with theadditional signal lines 13, 15, 17 and 37 which are added to allow theTAP 39 to access and control the user-implemented boundary scanregister. Control output from the instruction register of TAP 39 isshown at 41. FIG. 4 shows that the aforementioned conventional 1149.1test port signals are accessible at the external terminals of the IC.

In addition to providing the additional external signals mentionedabove, the IP core provider must design the instruction register of theTAP 39 to include all required 1149.1 instructions that are used by TAP11 (see FIG. 1) to access and control a core-provided boundary scanregister. The required 1149.1 boundary scan instructions are the Extestand Sample/Preload instructions. Also, the IP core provider must designthe instruction register of the TAP 39 to control the user-addedboundary scan register 25 exactly like a core-provided boundary scanregister would be controlled by TAP 11 under the influence of otherrequired instructions (e.g. conventional Bypass instruction), optionalinstructions (e.g. conventional Intest, HighZ, Clamp, Runbist, IDcode,and Usercode instructions), or proprietary IP core vendor-specificinstructions.

During a conventional Extest instruction, the conventional TAP 11 (seeFIG. 1) inhibits the operation of the IP core, connects the boundaryscan register to the IC's TDI and TDO pins, and controls the boundaryscan register to perform interconnect testing.

During a conventional Sample/Preload instruction, the conventional TAP11 enables the operation of the IP core, connects the boundary scanregister to the IC's TDI and TDO pins, and controls the boundary scanregister to be transparent, while functional signals flowing through theboundary scan register are captured and shifted out for inspection.

During a conventional Bypass instruction, the conventional TAP 11enables the operation of the IP core, connects the internal Bypassregister (an 1149.1 defined single bit test data register) to the IC'sTDI and TDO pins, and controls the boundary scan register to betransparent.

During a conventional Intest instruction, the conventional TAP 11 adaptsthe IP core for testing, connects the boundary scan register to the IC'sTDI and TDO pins, and controls the boundary scan register to performtesting on the IP core.

During a conventional HighZ instruction, the conventional TAP 11inhibits the operation of the IP core, connects the internal Bypassregister to the IC's TDI and TDO pins, and controls the boundary scanregister outputs to the high impedance state.

During a conventional Clamp instruction, the conventional TAP 11inhibits the operation of the IP core, connects the internal Bypassregister to the IC's TDI and TDO pins, and controls the boundary scanregister to a predetermined static input/output condition.

During a conventional Runbist instruction, the conventional TAP 11adapts the IP core for BIST testing, connects to the IC's TDI and TDOpins a specified internal test data register that will be used to accessthe pass/fail status of the BIST operation, and controls the boundaryscan register to a predetermined static input/output condition.

During a conventional IDcode instruction, the conventional TAP 11enables the operation of the IP core, connects the internal IDcoderegister (an 1149.1 specified 32-bit register for outputting vendoridentification and other information) to the IC's TDI and TDO pins, andcontrols the boundary scan register to be transparent.

During a conventional Usercode instruction, the conventional TAP 11enables the operation of the IP core, connects the internal Usercoderegister (an 1149.1 specified register for outputting additional vendorinformation) to the IC's TDI and TDO pins, and controls the boundaryscan register to be transparent.

With an IP core that provides the signals and instructions as describedabove, a user of the IP core need only design a boundary scan registeraround the IP core and connect the core-provided signal lines 13, 15 and17 to the user-added boundary scan register to achieve full 1149.1 testcapability, including boundary scan test capability. This approach isgood for the IP core provider in that, while it supports full 1149.1test capability, it does not require the IP core provider to degradeperformance by providing a boundary scan register in the IP core itself.The approach is good for the user of the IP core in that it allows theuser (e.g. an ASIC manufacturer) to decide whether to add the boundaryscan register and the attendant performance consequences. Also the easeof upgrading to full 1149.1 boundary scan testing by simply makingconnections between the IP core's TAP and a user-added boundary scanregister is a bonus for IC synthesis tool providers since the processcan be advantageously automated to push button placement and routing.

In example FIG. 5 it is seen that the 1149.1 instruction register withinthe IP core TAP comprises a capture-shift-update (CSU) register sectionand a decode section. During conventional 1149.1 instruction scans, theCSU register section captures status information present on its parallelinputs and then shifts data from TDI to TDO. During the shift operation,the captured status information is shifted out as a new instruction isshifted in. At the end of the 1149.1 instruction scan, the newinstruction shifted into the CSU register is updated and input to thedecode section. The decode section decodes the new instruction andoutputs control to cause the new instruction to take effect. Theinstruction can be, for example, any of the types previously mentioned.

When a user decides to connect a boundary scan register to an IP coreTAP having the external signal connections 13, 15 and 17 shown in FIGS.3 and 4, the user sets the external register present (ERP) signal to alogic state indicative of the presence of the user-added boundary scanregister. In this example, a high on ERP indicates the presence of auser-added ‘boundary scan register, and a low on ERP indicates theabsence of a user-added boundary scan register. As seen in FIG. 5, theERP signal is input to both the instruction CSU register and decodesections. The ERP is a status input (i.e. a capture input) to the CSUregister section. The ERP is an additional decode input to the decodesection.

During instruction scan operations, the ERP signal is captured andshifted out of the CSU register, along with other status inputs. Byexamining the ERP signal scanned from the CSU register, it is possibleto determine whether or not the user added a boundary scan register tothe IP core (for example ERP high=added, ERP low=not added). So the ERPinput to the instruction CSU register allows a user of the IC (e.g. asystem designer) to determine the presence or absence of a user-addedboundary scan register.

If the ERP is set high, indicating the presence of a user-added boundaryscan register, the decode section responds conventionally to 1149.1instructions that access and/or control the boundary scan register. Onthe other hand, if the ERP is set low, indicating the absence of auser-added boundary scan register, the decode section will preferablycause all 1149.1 instructions that normally access and/or control theboundary scan register to default to being Bypass instructions. Thiswould mean that Extest, Intest, Sample/Preload, HighZ, and Clampinstructions all default to the Bypass instruction when ERP is low.Defaulting to the Bypass instruction is preferred because that is thedefault instruction that 1149.1 conventionally uses forunknown/undefined instructions scanned into the instruction register.

FIG. 3A shows only the IP core within the broken-line box of FIG. 3, asit would be provided by the IP core vendor, that is, with core-providedsignal lines 13, 15 and 17 arranged to be available for convenientconnection as desired to a user-added scan register, and with thecore-provided ERP line 37 arranged to be available for convenientconnection to an appropriate logic level. If the core user does not adda boundary scan register, then lines 13, 15 and 17 will remainunconnected when the core is embedded in an IC.

Example FIG. 6 is similar to FIG. 3, but includes a further user-addedscan register. In example FIG. 6, a user-added general purpose scanregister 60 is shown interfaced to the IP core, in addition to thepreviously described user-added boundary scan register 25. In suchinstances, an additional signal indicates to TAP 39A the presence orabsence of the additional scan register, and the control lines at 17Aprovide control from TAP 39A to the scan register 60 as well as toregister 25. The scan input 15 and scan output 13 are used to accesseither the boundary scan or general purpose scan register. In FIG. 6,ERP is used, as previously described, to indicate the presence orabsence of the boundary scan register, and to enable access of theboundary scan register if it is present, or default to the bypassinstruction if it is not present. Likewise, the ERP1 signal is used toenable access of the general purpose scan register if it is present, orto default to the bypass instruction if it is not present and access ofit is attempted. The ERP and ERP1 signals are designated generally at37A in FIG. 6. Scan access to plural user-added scan registers operatesthe same as conventional 1149.1 scan access to plural core-provided scanregisters.

The user-added scan register(s) at 60 are located in the IC physicallyoutside of the core's boundary, that is, external relative to the core.The general purpose scan register 60 can be any scan register that doesnot perform boundary scan functions relative to the core boundary ofFIG. 6. Thus, scan register 60 could even have the same structure asboundary scan register 25, but would not function as a boundary scanregister relative to the core boundary. Also, the core design canprovide for addition of as many user-added scan registers as desired. Inthe arrangement of FIG. 6, the IP core user can easily control andaccess a user-added scan register other than a user-added boundary scanregister. User-added scan registers (such as 60) for general purposescan based input/output (110), via a core resident TAP, could serve manyapplications inside a system-on-a-chip such as expanded testing ofcircuits external to the core, user defined chip status bit monitoring,user defined chip control bit settings, and programming of electricallyprogrammable circuits inside the chip.

FIG. 6A relates to FIG. 6 as FIG. 3A relates to FIG. 3, showing only theFIG. 6 IP core as it would be provided by the IP core vendor.

Although exemplary embodiments of the present disclosure are describedabove, this description does not limit the scope of the disclosure,which can be practiced in a variety of embodiments.

1. An integrated circuit comprising: A. a semiconductor substrate; B.functional circuits formed on the substrate, the functional circuitsincluding at least one set of IP core circuits, the IP core circuitsincluding: i. core functional circuits formed on the substrate, the corefunctional circuits forming a periphery on the substrate and having corefunctional input leads and core functional output leads that extendbeyond that periphery, the core functional input leads and corefunctional output leads being free of any connection to any boundaryscan circuits within the periphery of the core functional circuits; andii. test circuits formed on the substrate within the periphery of thecore functional circuits, the test circuits including a test access portand test data registers, the test circuits including: a. a test datainput lead extending beyond the periphery of the core functionalcircuits; b. a test data output lead extending beyond the periphery ofthe core functional circuits; c. a test clock lead extending beyond theperiphery of the core functional circuits; d. a test mode select leadextending beyond the periphery of the core functional circuits; e. asecond test data input lead extending beyond the periphery of the corefunctional circuits; f. a second test data output lead extending beyondthe periphery of the core functional circuits; and g. control signalleads extending beyond the periphery of the core functional circuit; C.first scan circuits serially formed on the substrate outside of theperiphery of the IP core circuits, the first scan circuits being formedbetween and connecting together the core functional input leads and therest of the functional circuits, the first scan circuits being formedbetween and connecting together the core functional output leads and therest of the functional circuits, and the first scan circuits beingconnected to the second test data input lead, the second test dataoutput lead, and the control signal leads; and D. second scan circuitsformed on the substrate outside of the periphery of the IP corecircuits, the second scan circuits being separate from the first scancircuits, and the second scan circuits being connected to the secondtest data input lead, the second test data output lead, and the controlsignal leads.
 2. The integrated circuit of claim 1 in which the controlsignal leads extend within the IP core circuits, and the test circuitsinclude data registers connected to the test data input lead and thecontrol signal leads.
 3. The integrated circuit of claim 1 in which thefirst scan circuits are boundary scan circuits connected with the corefunctional input leads and core functional output leads.
 4. Theintegrated circuit of claim 1 in which the second scan circuits aregeneral purpose scan circuits free of connection with the corefunctional input leads and core functional output leads.